The present invention relates generally to computer systems and more particularly to a method and apparatus for dynamically rendering components at run time.
For a number of years now, database management systems have been used to store and to manage data critical to a company""s operation, such as sales data, employee data, and customer information. One type of database management system that has emerged as the most prevalent is the relational database management system (RDBMS). In an RDBMS, information is stored in structures known as tables. A table typically comprises a plurality of columns and rows, with each column representing an attribute of a record and each row representing a particular record. In a relational database, information is manipulated by way of queries. A query is a statement that specifies which attributes of which records are to be manipulated, and what operations are to be performed on them. A query is typically written using a structured query language, such as SQL, that is understood by the RDBMS. When a query is submitted, the RDBMS parses and executes the query to manipulate the data as specified. In a relational database, queries can be used to perform all data manipulations, including insert, retrieve, update, and delete.
Queries are powerful tools for manipulating data in a relational database. However, their usefulness may be limited by the amount of knowledge that they require on the part of the user. In order to construct a query, a user needs to be familiar with the structured query language used by the RDBMS. Such a language can be fairly complex and difficult to master. In addition, the user needs to know what information is stored in which tables. This in turn requires that the user be familiar with the schema of the database. In many implementations, end users of the database do not possess this level of sophistication. Hence, they cannot effectively interact with the database using queries.
To facilitate interaction between users and the database, applications such as forms and reports are typically developed. In a typical RDBMS, a form is used to insert, update, and delete information from the database. A report is usually used to retrieve mass amounts of information from the database and to present the information to the user in a particular format. Other applications have also been developed to present information to the user in other formats, including charts, menus, and hierarchies. One of the major underlying purposes of an application is to provide an interface for enabling a user to interact with the database without having to manually formulate queries. Queries are still used to interact with the RDBMS, but the burden of generating and manipulating the queries is on the application, not the end user. In essence, an application transfers the complexity of interacting with a database from the end user to the application developer.
Currently, applications are developed using one of two major methodologies. The first methodology involves writing actual computer code to define the functionality of the application. The application may be written in one of many different computer languages including C, C++, and Java. Using the chosen language, the developer defines the layout of the application and sets forth the logic for implementing the desired functionality. Once written, the application is stored as a static set of code, either in compiled form or as a source file. At run time, the application is executed just like any other program to enable a user to interact with the database. According to this methodology, each application is a separate and distinct executable entity. Thus, there needs to be a separate executable file for each and every form, report, etc.
A second methodology involves the use of an application development tool, such as Developer 2000 manufactured by Oracle Corporation of Redwood Shores, Calif. An application development tool typically comprises a design time engine and a run time engine. Using the design time engine, a developer defines the format of an application. The developer can also specify logic for controlling the functionality of the application. Once the defining process is completed, the design time engine generates an application, and stores it away as a static entity. One of the advantages of using a development tool is that it relieves the developer of having to write any actual computer code. Once the application is generated by the design time engine, it is ready for execution. At run time, the run time engine interprets the application, and renders the format and functionality defined by the developer. According to this methodology, each application is stored as a separate and distinct entity. Thus, as was the case with the first methodology, there needs to be a separate entity for each and every form, report, etc.
These two methodologies are generally effective for developing applications; however, they do have significant drawbacks which render them impracticable in certain implementations. One such drawback is that they require a relatively high level of sophistication from the application developer. With the first methodology, the developer needs to be a skilled programmer, having familiarity with both a programming language and the workings of a database. With the second methodology, while the developer is no longer required to write actual computer code, the developer still needs to learn to use the development tool. With a development tool such as Developer 2000 which has a deep and robust set of capabilities, the learning process can be quite involved. In many implementations, it would be desirable to have relatively unsophisticated users define and deploy applications. In such implementations, these two methodologies cannot be used.
Also, note that according to both methodologies, each application is stored as its own separate static entity. This means that for every form, report, or any other application used by a company, a separate static entity is stored and maintained. For large companies, the number of different applications can easily run into the thousands. With this large number of applications, the storage needed for all of the separate entities can be enormous. The process of maintaining and updating the entities can also be extremely tedious. In light of these shortcomings, an improved methodology for developing and deploying applications is needed.
To overcome the shortcomings of the prior art, the present invention provides an improved application development/deployment mechanism which enables relatively unsophisticated users to develop applications, and which does not require each application to be stored as its own large static entity. According to the present invention, there is provided a generic builder engine and a plurality of generic component rendering engines. As used herein, the term component refers to any application or any portion of an application for facilitating interaction between a user and a database, including but not limited to forms, reports, menus, charts, and hierarchies.
The general purpose of the builder engine is to make it simple for a user to define a particular component (i.e. to develop an application). The builder engine solicits from the developer, through a simple dialog, all of the information needed to define the component. In effect, the builder engine guides the developer through the defining process, thereby enabling a relatively unsophisticated developer to define a component. In one embodiment, the builder engine takes the form of a generic engine which solicits information from a developer based upon predefined metadata . More specifically, for each type of component that a developer can define, there is an associated set of predefined metadata. This metadata specifies what information needs to be solicited from the developer to define an instance of that type of component, and how that information should be solicited. Based upon this metadata, the generic builder engine dynamically generates one or more display pages to solicit the necessary information from the developer. In this manner, the builder engine guides the developer through the process of defining a component.
Implementing the builder engine in this generic manner is quite advantageous because it makes it possible for a single engine to be used to guide a developer through the defining process for all possible types of components. To add a new type of component, all that needs to be done is to add a set of predefined metadata describing the new component type. The builder engine will thereafter be able to guide a user through the defining process for that type of component. To change an existing component type, all that needs to be done is to change the predefined metadata associated with that type. The builder engine will thereafter reflect the change. No changes need to be made to the builder engine. Thus, the builder engine of the present invention is quite versatile and efficient.
Once the builder engine solicits and receives all of the necessary information from the developer to define a particular component, the information is stored as metadata associated with that particular component. This metadata differs from the predefined metadata used by the builder engine in that the predefined metadata pertains to a type of component (e.g. report, form, etc.) whereas this metadata pertains to a particular instance of a type of component (e.g. xe2x80x9creport 101xe2x80x9d,xe2x80x9cform 203xe2x80x9d). The metadata for a particular component specifies all of the necessary details to define the format of the component. The term format is used herein in a very broad sense to encompass the xe2x80x9clook and feelxe2x80x9d as well as the functionality of the component. Once the metadata for a particular component has been defined, the component is ready to be rendered (i.e. executed).
At run time, one of the generic rendering engines is invoked to dynamically generate the particular component. In one embodiment, a rendering engine is provided for each type of component (e.g. a chart rendering engine, a form rendering engine, etc.), and each engine is responsible for rendering all instances of that type. In generating a particular component, a rendering engine uses the metadata associated with that component. Each rendering engine is constructed in such a way that it understands the metadata associated with a component, and contains logic for implementing the functionality specified by the metadata. In effect, the rendering engines are responsible for implementing the format specified by the metadata.
An important point to note is that unlike the prior art methodologies, the present invention does not create a component (i.e. application) at design time and store it away as a static entity ready for execution. Rather, the present invention uses metadata at run time to dynamically generate a component. Thus, according to the present invention, a component is both generated and executed at run time. Rendering components in this manner is advantageous in at least two respects. First, it eliminates the need to store components as individual static entities. Because components are generated dynamically at run time using metadata, only the metadata needs to be stored. This serves to significantly reduce storage requirements. Second, the present invention significantly reduces code redundancy. In a system having a large number of applications, it is generally true that many of the applications contain identical code. Because the present invention uses the same generic rendering engine to render all components of a particular type, the code is centralized to the rendering engine. Due to this code centralization, there is practically no code redundancy. Overall, dynamically rendering components in accordance with the present invention leads to greater system efficiency.